In a typical computing device such as a personal computer or the like, the computing device is operated based on an operating system or the like that is instantiated on the computing device. As may be appreciated, such an operating system among other things may maintain a user account for each of one or more users that may employ the computing device, where each user account among other things may specify rights and privileges (hereinafter, ‘privileges’) that the corresponding user has with respect to the computing device. For example, the user account for a particular user may specify whether the user can instantiate applications on the computing device, whether the user can install applications on the computing device, whether the user can alter the operating system of the computing device, whether the user can access files of other users on the computing device, and the like.
Significantly, when a user logs on to such an operating system, the operating system may create a token describing the privileges of the user based on the user account thereof, where such token is then attached to a base process or the like. As may be appreciated, such a base process is likely a shell or other base platform from which other processes may be instantiated. As may also be appreciated, such a token is a software construct or the like and rests in a memory of the computing device. Thus, such attachment of such a token is likely conceptual in nature, and may for example comprise providing the base process with a pointer or other reference to the created token.
At any rate, with the attached token, the operating system allows the base process to operate only in accordance with the privileges of the user as set forth within the attached token. For example, if the base process wishes to read data from a particular location or change system time, the operating system in fact allows the base process to read the data or to change the system time only if the attached token so allows based on the privileges set forth therein. Generally, employing an attached token to specify privileges for a process running on an operating system of a computing device is known or should be apparent to the relevant public and therefore need not be set forth herein in any detail.
Note that when a first process on an operating system creates a second process on the operating system, the operating system typically copies the token of the first process and attaches such copied token to the second process. Thus, without more, the second process has the same privileges on the operating system as the first process inasmuch as the copied token of the second process specifies the same privileges as the token of the first process. However, it may be the case that the first process in the course of creating the second process wishes to restrict the privileges of the second process. If so, and as is known, the operating system copies the token of the first process for the second process and then removes certain privileges therefrom prior to attaching such copied token to the second process. Here, then, the second process has less privileges on the operating system as compared with the first process. Typically, a first process can assign to a second process only as many privileges as such first process may possess, and no more. Thus, the privileges of the second process as specified in the token thereof are a sub-set of the privileges of the first process as specified in the token thereof.
Based on the above, then, it is to be appreciated that a user of an operating system on a computing device may be logged on thereto according to a user account that has full privileges. Consequently, any application program that such a full-privilege user may instantiate on the computing device is, without more, accorded full privileges. However, and significantly, an application instantiated with full privileges presents a security risk to the operating system inasmuch as such a full-privilege application is not restricted from performing harmful, deceptive, or malicious actions. Thus, a full-privilege user may directly or indirectly instantiate an application with full privileges, and such application intentionally or unintentionally may exploit the full privileges provided thereto, for example, to modify files on the computing device, to modify the operating system, or even to take control of critical operating system behavior.
Accordingly, a need exists for a method and mechanism by which the process of an application or the like is provided with a token that contains only a limited set of privileges, whereby such a limited privilege token only allows the process to perform a limited set of actions which presumably are not harmful, deceptive, or malicious. In particular, a need exists for such a method and mechanism whereby a user upon logging on to a computing device is provided with both a limited privilege token with a limited set of privileges and a full privilege token with a full set of privileges, whereby processes that are not deemed to be especially trustworthy may be instantiated on the computing device based on the limited privilege token of the user, and processes that are deemed to be especially trustworthy may be instantiated on the computing device based on the full privilege token of the user.